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Abstract. The initial descriptions of the FITS format provided a simplified method for describing the physical coordinate 
values of the image pixels, but deliberately did not specify any of the detailed conventions required to convey the com- 
plexities of actual image coordinates. Building on conventions in wide use within astronomy, this paper proposes general 
extensions to the original methods for describing the world coordinates of FITS data. In subsequent papers, we apply these 
general conventions to the methods by which spherical coordinates may be projected onto a two-dimensional plane and to 
frequency/wavelength/velocity coordinates. 
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1. Introduction 

The Flexible Image Transport System, or FITS format, was first 



described by Wells et al. (1981). This format is characterized 



by a fixed logical record length of 2880 bytes, and the use of an 
unlimited number of character-format "header" records with an 
80-byte, keyword-equals-value substructure. The header is fol- 
lowed by the header-specified number of binary data records, 
which are optionally followed by extension records of the spec- 
ified length, but, at that time, of unspecified format. Since then, 
a number of authors hav e sugg ested various ty pes of extensions 



■ I— I , al. 



(e. g. Gre isen & Hart en |198U Grosb0l et al. |1988| ; Harten et 



19881 ; Cotton et al. |1995| ). Because of its great flexibility, the 



FITS format has been, and continues to be, very widely used 
in astronomy. In fact, the FITS tape format was recommended 
(resolution CI) for use by all observatories b y Com mission 
5 at the 1982 meeting of the lAU at Patras ( |1983| ) and the 
General Assembly of the lAU adopted (resolution Rl 1) the rec- 
ommendations of its commissions, including the FITS resolu- 
tion. A committee of the NASA/Science Office of Standards 
and Technology has codified the current state of FITS into a 
document which has been accepted as the official definition of 
the standard (Hanisch et al. 2001 1. 



Wells et al. (1981 ) anticipated the need to specify the phys- 
ical, or world, coordinates to be attached to each pixel of an 
A^-dimensional image. By world coordinates, we mean co- 
ordinates that serve to locate a measurement in some multi- 
dimensional parameter space. They include, for example, a 
measurable quantity such as the frequency or wavelength as- 
sociated with each point in a spectrum or, more abstractly, the 
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longitude and latitude in a conventional spherical coordinate 
system which define a direction in space. World coordinates 
may also include enumerations such as "Stokes parameters", 
which do not form an image axis in the normal sense since in- 
terpolation alon g such axes is not meaningful. 

Wells et al. ( 1981 ) viewed each axis of the image as hav- 
ing a coordinate type and a reference point for which the pixel 
coordinate, a coordinate value, and an increment were given. 
Note that this reference point was not required to occur at inte- 
ger pixel locations nor even to occur within the image. An un- 
defined "rotation" parameter was also provided for each axis. 
Since there are, in general, more coordinates to be attached to 
a pixel than there are "real" axes in the A^-dimensional image, 
the convention of declaring axes with a single pixel was also es- 
tablished in both examples given by Wells et al. The keywords 
defined were 

CRVALn coordinate value at reference point 

CRPIXn array location of the reference point in pixels 

CDELTn coordinate increment at reference point 

CTYPEn axis type (8 characters) 

CROTA« rotation from stated coordinate type 

A list of suggested values for CTYPEn was provided with few 
of the details actually required to specify coordinates. The units 
were specified to be The International System of Units "SI" 
(meters, kilograms, seconds) with the addition of degrees for 
angles. 

The simplicity of this initial description was deliberate. It 
was felt that a detailed specification of coordinate types was a 
lengthy and complicated business, well beyond the scope in- 
tended for the initial paper. In addition, the authors felt that 
a detailed specification would probably be somewhat contro- 
versial and thus likely to compromise the possibility of wide- 
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spread agreement on, and use of, the basic structures of the for- 
mat. Hindsight also suggests that we were rather naive at the 
time concerning coordinates and it is fortunate that the detailed 
specification was postponed until greater experience could be 
obtained. 

The descriptions of coordinates in the initial FITS paper are 
simply inadequate. They provide no description of the meaning 
of the world coordinates and suggest a rather incomplete list of 
coordinate types. The use of a single rotation per axis cannot 
describe any general rotation of more than two axes. 

While participating in the development of the AIPS soft- 
ware package of the National Radio Astronomy Observatory, 
Greisen (1983, 1986) found it necessary to supply additional 
details to the coordinate definitions for both spectral and ce- 
lestial coordinates. Since the latter have been widely used, 
a NASA-sponsored conference held in January 1988 recom- 
mended that they form the basis for a more general coordinate 
standard (Hanisch & Wells 1988 ); such a standard is described 
below. 

The present work generalizes the set of world coordinate 
system (WCS) FITS keywords with a view to describing non- 
linear coordinate systems and any parameters that they may 
require. Alternate keywords which should be supported are de- 
scribed. It also addresses the questions of units, multiple co- 
ordinate descriptions, uncertainties in the coordinate values, 
and various other coordinate related matters. Conventions for 
attaching coordinate information to tabular data are also de- 
scribed. Paper II (Calabretta & Greisen 2002) and Paper III 
(Greisen et al. 2003) extend these concepts to the ideal, but 
non-linear angular and spectral coordinates used in astronomy. 



Paper IV (Calabretta et al. 2003) then provides methods to de 



scribe the distortions inherent in the image coordinate systems 
of real astronomical data. The complex questions related to 
time systems and to other kinds of coordinates will be deferred. 
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Fig. 1. Conversion of pixel coordinates to world coordinates 
shown as a multi-step process. In the first step a Unear trans- 
formation is applied via matrix multiplication of the pixel co- 
ordinate vector This linear transformation may be restricted 
to the geometrical effects of rotation and skewness with scal- 
ing to physical units deferred until the second step {PCLj plus 
CDELT/ formalism). Alternatively, scaling may be applied via 
the matrix with the second step omitted (CD/_7 formalism). The 
final step applies a possibly non-linear transformation to pro- 
duce the final world coordinates. Although generic keywords 
for this step are defined in this paper, the mathematical details, 
including the interpretation of the intermediate world coor- 
dinates, are deferred to later papers which may also interpose 
additional steps in the algorithm chain. For later reference, the 
mathematical symbols associated with each step are shown in 
the box at right. 



2. Basic concepts 

2.1. Coordinate definition and computation 

In the current proposal, we regard the conversion of pixel co- 
ordinates to world coordinates as a multi-step process. This is 
illustrated conceptually in Fig. |l], which shows only the steps 
to be discussed here. Later extensions may interpose additional 
steps as required. For example. Paper II divides the final step 
into two with the computation of intermediate spherical coor- 
dinates that are subsequently converted to celestial coordinates 
via a spherical rotation. Paper IV interposes optional distor- 
tion corrections between the first and/or second steps of Fig. |l]. 
Generally these are intended to account for small residuals that 
cannot be described by one of the standard world coordinate 
transformations. These may arise in a variety of ways; natu- 
rally (e.g. aberration or atmospheric refraction), via complex 
instrumental response functions (e.g. data cubes produced by 
a Fabry-Perot interferometer for which surfaces of constant 
wavelength are curved), by the intrinsic nature of the system 
under study (e.g. surface coordinates of the asteroid Eros), or 
as a result of instrumental peculiarities. 



2.1 .1 . Basic formalism 

For all coordinate types, the first step is a linear transformation 
applied via matrix multiplication of the vector of pixel coordi- 
nate elements, pf 



(1) 



where rj are the pixel coordinate elements of the reference 
point given by the CRPIX j. Henceforth we will consistently 
use j for pixel axis indexing and / for the world axes. 

The niij matrix is a non-singular square matrix of dimen- 
sion N X N. In the first instance, is given by the NAXIS key- 
word value, but this will be gene raliz ed with the introduction 
of the WCSAXES keyword in Sect. 2/2 so that the dimension of 
the world coordinates need not match that of the data array. 

The elements, qi, of the resulting intermediate pixel coor- 
dinate vector are offsets, in dimensionless pixel units, from the 
reference point along axes coincident with those of the inter- 
mediate world coordinates. Thus the conversion of qi to the 
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corresponding intermediate world coordinate element, x,, is a 
simple scale: 

Xi = Siqi . (2) 

We defer discussion of th e encoding of m,/ and i, as FITS 
header cards to Sect. 2.1.2. 



The third step in the process of computing world coordi- 
nates depends on the CTYPE /. For simple linear axes, the jc, are 
interpreted as offsets to be added to the coordinate value at the 
reference point given by CRVAL/. Otherwise, the CTYPE; define 
a function of the x,, the CRVAL/, and, perhaps, other param- 
eters that must be established by convention and agreement. 
Any CTYPE i not covered by convention and agreement shall be 
taken to be linear. 

Non-linear coordinate systems will be signaled by CTYPE / 
in "4-3" form; the first four characters specify the coordinate 
type, the fifth character is a and the remaining three char- 
acters specify an algorithm code for computing the world coor- 
dinate value, for example ' ABCD-XYZ ' . We explicitly allow the 
possibility that the coordinate type may augment the algorithm 
code, for example 'FREQ-F2W' and 'VRAD-F2W' may denote 
somewhat different algorithms (see Paper III). Coordinate types 
with names of less than four characters are padded on the right 
with and algorithm codes with less than three characters 

are padded on the right with blanks, for example ' RA UV ' . 

However, we encourage the use of three-letter algorithm codes. 

Particular coordinate types and algorithm codes must be es- 
tablished by convention. Paper II constructs the framework for 
celestial coordinate systems, and Paper III does so for spec- 
tral axes (frequency-wavelength-velocity). CTYPE; values that 
are not in "4-3" form should be interpreted as linear axes. It is 
possible that there may be old FITS files with a linear axis for 
which CTYPE; is, by chance, in 4-3 form. However, it is very 
unlikely that it will match a recognized algorithm code (use of 
three-letter codes will reduce the chances). In such a case the 
axis should be treated as linear. 



interpret CDELT;, so it makes sense for CDELT; to retain its 
original function. 

The transformation matrix then replaces the poorly defined 
CROTA; with a nomenclature that allows for both skew and 



2.1.2. Linear transformation matrix 

The proposal to replace the CROTA; keywords of Wells et 



al. (1981) with a general linear transformation matrix dates 



from Hanisch & Wells (1988), although the details of its im- 
plementation have undergone considerable evolution. The main 
point of divergence has been whether the matrix should com- 
pletely replace or simply augment the CDELT;, but there are 
also important differences relating to the default values of the 
matrix elements. 

In defining a nomenclature which augments the CDELT; we 
have been guided by the following considerations: 

• Where possible, standards should grow by generalizing ex- 
isting usage rather than developing a separate parallel us- 
age. Augmenting the existing CDELT; with a separate trans- 
formation matrix that defaults to unity makes old headers 
equivalent to new ones that omit the keywords that define 
the transformation matrix. In any case, the "once FITS, al- 
ways FITS" rule means that FITS readers must continue to 
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fully general rotations. We do not consider this replacement 
and the consequent deprecation of the CROTA/ to be incon- 
sistent with the aim of generalizing existing usage since, to 
our knowledge, the CROTA; have had no formal definition 
other than the "MPS convention" (Greisen 119831, |1986|). 



and the 



Both Wells et al. ( 198 1 1 and Hanisch et al. ( 2001 ) state that 



"users of this option should provide extensive explanatory 
comments." Paper II describes the translation of the AIPS 
interpretation of CROTA/ to the new formalism. 

• A large fraction of WCS representations, perhaps the great 
majority, will not require the general linear transformation. 
FITS writers may continue to use CDELT/, so FITS-writing 
software need not be rewritten to conform to the new for- 
malism unless it needs the new features. 

• The physical units of a general image may differ by many 
orders of magnitude, from frequencies of lO'" Hz (or more) 
to angles of 10"^ degrees (or less). If the physical units en- 
ter into the linear transformation matrix, then the elements 
of that matrix will have very different magnitudes. These is- 
sues pose difficulties both in computing and in understand- 
ing, and it may be simpler to defer application of physical 
units until the multiplication by CDELT/. 

• These difficulties are compounded when correcting for the 
distortions present in real instruments. Paper IV will show 
that some instruments require distortion corrections before, 
and others after, the linear transformation matrix. Such cor- 
rections may need to be expressed in terms directly re- 
lated to pixel coordinates. If the physical units enter into 
the Unear transformation matrix, then the distortion correc- 
tions which come after the matrix would have to compen- 
sate for the physical units applied by it, effectively undoing 
and then redoing a multiplication by CDELT/. Furthermore, 
commensurability problems may arise when recording the 
maximum distortion correction for a WCS representation 
that mixes pre-, and post-corrections between axes. 

• A widely used formalism that discards CDELT/ was de- 
veloped by the Space Telescope Science Institute for the 
Hubble Space Telescope and was incorporated generally in 
the IRAF data analysis system. We therefore support this as 
an alternative method. 

In the PC/_7 formalism, the matrix elements niij are en- 
coded in 



PC/-7 



(floating-valued) 



header cards, and i, as CDELT/. The / and j indices are used 
without leading zeroes, e.g. PC1_1 and CDELT 1. The default 
values for PCi_j are 1.0 for / = j and 0.0 otherwise. The 
PCiJ matrix must not be singular; it must have an inverse. 
Furthermore, all CDELT / must be non-zero. In other words, in- 
vertibility means that transformations which project from an 
initial coordinate system of dimensionality WCSAXES to a world 
coordinate system of dimensionality less ffian WCSAXES are for- 
bidden. 

In the CD/_7 formalism Eqs. (|l]) and (^ are combined as 

N 



CD/_; 



(floating-valued) 



keywords encode the product i,m,y. The / and j indices are used 
without leading zeroes, e.g. CD1_1. The CD/_j matrix must not 
be singular; it must have an inverse. CDELT/ and CROTA/ are 
allowed to coexist with CDLj as an aid to old FITS interpreters, 
but are to be ignored by new readers. The default behavior for 
CD/_j differs from that for PC i-j; if one or more CD/_y cards are 
present then all unspecified CD/_j default to zero. If no CD/.J 
cards are present then the header is assumed to be in PC ij form 
whether or not any PC/_y cards are present since this re sults i n 
an interpretation of CDELT / consistent with Wells et al. ( 1981 ). 

We specifically prohibit mixing of the PC/_y' and CD/_y 
nomenclatures in any FITS header data unit. Wiffi ffiis restric- 
tion, translation from the CD/_y formalism to the PC/_j formal- 
ism is effected simply in the keyword parsing stage of header 
interpretation; the CD/_/ should be considered equivalent to the 
PC/_y subject to the considerations for default values noted 
above and with CDELT/ set to unity. Similarly, CD/.y can be 
calculated from PCiJ and CDELT / following Eq. |3} 

2.1.3. Usage comments 

The proposal presented in this and the subsequent papers is not 
simple and provides wide latitude for mistakes in describing 
the WCS and in writing the FITS headers. The result of an 
improperly described WCS is simply undefined; it is the job of 
the FITS writer to produce a correct description. A simple error 
which could be made in a WCS description, or with other parts 
of a header, is a repetition of keywords with different values 
assigned to them. If, for example, BUNIT were repeated with 
a new value, the data would have unknown units but would 
be read correctly. In binary tables, a second value for TFORMn 
would cause the tabular data to be read incorrectly. 

This is a very general proposal! The linear transformation 
matrix allows for skew and fully general rotations. The reader 
should note that this allows dissimilar axes to be rotated into 
one another This is meaningful in imaging; for example, one 
may wish to re-sample a spectral-line cube from some special 
viewing angle in the three-space of two celestial coordinates 
and one frequency coordinate. Such rotations are, however, for- 
bidden into axes whose coordinate values are, by convention, 
only integral. Thus, if CTYPE/o indicates a world coordinate 
of integral type, then row /q of the linear transformation ma- 
trix must contain only one non-zero element, and this would 
normally be 1.0 or at least integral. Additionally, it must be the 
only non-zero element in the column containing it. The STOKES 
axis is one such coordinate; see Sect. 5.4. 



The linear transformation matrix could also be used to rep- 
resent images that have been transposed, e.g. 



PC = 



(0 1 

1 

1 



(3) 



This is a legal usage, but likely to confuse the reader. In 
this example, the FITS user will read in the header that ffie 
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first element of the world coordinate is CTYPEl, although 
this corresponds to the second pixel axis. Note that keywords 
NAXISl, CRPIXl, PC;_1, and CD;_1, for example, all refer to 
the first pixel axis in the image, while CTYPEl, CRVALl, PC IJ, 
CD l_j, and CDELTl all refer to the first world coordinate ("^i" 
and "xi") element. They must produce a correct result when 
Eqs. (|l]) and or Eq. (^) are applied. Thus, xi is of type 
CTYPEl even if it does not change with pi (to use the nomen- 
clature of Eqs. (|l]), (^, and (^). Therefore, it is good form to 
transpose the header parameters along with the image so that 
the on-diagonal terms in the transformation matrix predomi- 
nate. If the PC or CD matrix is essentially diagonal, then the 
human reader of the FITS header will have a better chance of 
understanding the coordinate representation. 

Equations (|l]) and allow considerable flexibility in the 
way the linear transformation is partitioned between the PC i_j 
and CDELT/. In the absence of any formal constraints, the nor- 
mal expectation would be that the CDELT / be used as scaling 
parameters as in the past. This is straightforward if PC Lj is or- 
thogonal, i.e. defines a pure rotation or simple reflection, but 
not if it has an element of skewness. In general, a reasonable 
approach is to choose CDELT / so that 



N 



(4) 



for all /. This normalization leaves orthogonal matrices un- 
changed, and only slightly modifies matrices which are nearly 
orthogonal. Note that this is not the same as setting the determi- 
nant of the PC i_j matrix to unity. Note also that this constraint 
is optional and may not be the most physically meaningful se- 
lection of the PC/_y. For example, the conversion from the old 
CROTA/ nomenclature to the new PCiJ form described in Paper 
II does not satisfy this constraint unless the CDELT / are equal. 

2.1.4. Additional points 

Note that integer pixel numbers refer to the center of the pixel 
in each axis, so that, for example, the first pixel runs from pixel 
number 0.5 to pixel number 1.5 on every axis. Note also that 
the reference point location need not be integer nor need it 
even occur within the image. The original FITS paper (Wells 
et al. 1981 ) defined the pixel numbers to be counted from 1 to 



NAXIS j {> 1) on each axis in a Fortran-like order as presented 
in the FITS image.f] 



' This convention differs from the usual practice in computer graph- 
ics where the pixels are counted from z ero with pixel centers as half in- 



tegers (e.g. Adobe Systems, Inc. 1999). The convention proposed here 



has been used extensively in FITS since the format was invented and 
no argument has been advanced sufficiently compelling to invalidate 
the many thousands of files written with that convention. Furthermore, 
we regard our image samples as "voxels" in real physical space rather 
than pixels in two-dimensional display space. As such, they may be 
viewed from any angle via transposition and rotation. The only point 
within the individual voxel that remains invariant under those opera- 
tions is its center and we argue, therefore, that it is the center of the 
voxel which we should count. 



A WCS representation should be invertible in the sense that 
a pixel coordinate, when transformed to a world coordinate, 
must be uniquely recoverable from that world coordinate. Note 
that this does not require that each pixel coordinate in an im- 
age have a valid world coordinate; as an example, pixel coor- 
dinates in the corner of a Hammer- AitofF projection of the full 
sky fall outside the map boundary. Nor need each valid world 
coordinate correspond to a pixel coordinate; for example, the 
divergent poles of the Mercator projection are inaccessible. In 
practical terms, it means that two or more diff'erent pixel coor- 
dinates should not map to the same world coordinate, as exem- 
plified by a cylindrical projection in which the longitude spans 
more than 360°. Such coordinate systems, while easy to con- 
struct, may be very difficult to interpret properly in all respects, 
including that of drawing a coordinate grid. Thus, while they 
are not explicitly prohibited, it may be expected that general 
WCS interpreting software may not handle them properly. 

An additional convention is needed where non-linear axes 
must be grouped, for example, the two axes which form a map 
plane. In general, all axes in the group must have identical al- 
gorithm codes and a scheme must be established by convention 
for associating members of the group and, if necessary, their 
order For example. Paper II introduces the 'jcLON/jcLAT' and 
'yzLN/yzLT' conventions for associating longitude/latitude co- 
ordinate pairs. This should serve as a model for other cases. 
Note that grouping is not required for linear axes which are 
always separable (in the mathematical sense) by means of a 
rotation or skew applied via the linear transformation matrix. 

Some non-Unear algorithms require parameter values, for 
example, conic projections require the latitudes of the two stan- 
dard parallels. Where necessary, numeric parameter values will 
be specified via 



PV/_m 



(floating-valued) 



keywords, where / is the intermediate world coordinate axis 
number and m is the parameter number Leading zeros are not 
allowed and m may have only those values defined for the par- 
ticular non-Unear algorithm in the range through 99 only. 
There may also be auxiliary keywords which are required to 
define, for example, the frames of reference used for celestial 
and velocity coordinates. 

A few non-linear algorithms may also require character- 
valued parameters, for example, table lookups require the 
names of the table extension and the columns to be used. Where 
necessary, character- valued parameters will be specified via 



PS ijn 



(character-valued) 



keywords, where / is the intermediate world coordinate axis 
number and m is the parameter number Leading zeros are not 
allowed and m may have only those values defined for the par- 
ticular non-linear algorithm in the range through 99 only. 

The keywords proposed above and throughout the main 
body of this manuscript apply to the relatively simple images 
stored in the main FITS image data and in IMAGE extensions 



Ponz et al. 1994). When coordinates are used to describe image 



fragments in BINTABLE extension tables (Cotton et al. 1995) 



additional nomenclature conventions are required. These are 
described in Sect. ||. 
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2.2. Coordinate dimensionality 

The number of world coordinate elements associated with a da- 
tum can exceed the number of pixel coordinate elements which 
locate it in the image data array. For example, long-slit opti- 
cal spectra are naturally two-dimensional; normally the slit is 
aligned with one (spatial) pixel axis and the dispersion coin- 
cides with the other (spectral) pixel axis. While the spectral rep- 
resentation is straightforward - one spectral pixel coordinate 
transforms to just one spectral world coordinate (frequency, 
wavelength or velocity) - the spatial representation would ap- 
pear to be problematic. Since the slit can be oriented at any 
angle on the sky, the single pixel coordinate which locates a 
datum along the length of the slit must transform to two spatial 
(angular) coordinates, typically a right ascension and a decli- 
nation, neither of which need be constant. 

In fact, this problem was solved very early in the history of 
FITS. Wells et al. (1981) illustrate headers containing degener- 
ate axes, i.e. axes having NAXIS j - 1, and this, combined with 
the meaning assigned to CROTA/ by Greisen (1983 1, provides 
a fully functional solution. While not previously documented 
outside the AIPS project, this solution is well known and has 
been used extensively. Basically the idea is simply to increment 
the number of pixel coordinate elements as required by intro- 
ducing degenerate axes. 

For the long slit example, we set NAXIS = 3 and 
NAXIS 3 = 1. Supposing without loss of generality that CTYPEl 
is the spectral axis, we represent CTYPE2 as right ascension 
and CTYPE3 as declination. CROTA; in the original formula- 
tion is here replaced by PC so that pixel coordinates along 
the length of the slit, (p2,P3 = 1), transform to intermediate 
world coordinates (x,y). Thus the slit's locus in the A:}'-plane is 
a straight line whose orientation can be controlled via the PC i_j 
matrix. Details of the transformation of (x, y) to celestial spher- 
ical coordinates are properly the subject of Paper II. However, 
given that the xy-plane is to be interpreted as the map plane of 
a spherical projection, it should be clear that rotating the slit in 
the xy-plane via the PCiJ matrix corresponds to rotating it on 
the sky. Paper II discusses this long slit example in detail. 

There is concern that requiring the use of degenerate pixel 
axes would have severe repercussions for a significant fraction 
of existing software programs which were not written to deal 
with such usage. For example, some software intended to han- 
dle two-dimensional images would reject a FITS header with 
NAXIS - 3, even if the third axis is degenerate. At the same 
time, degenerate axes are a widespread and natural representa- 
tion for images in a multi-dimensional space. Furthermore, as 
shown in Fig. 1 of Wells et al. (1981), explicit specification of 
degenerate axes allows them to appear in any order. Such usage 
may facilitate image building and sub-imaging operations. 

To provide a solution for this world-coordinate dimension- 
ality problem that does not require the use of degenerate axes, 
we reserve the keyword 



CTYPEi, CRVAL/, or CUNIT/). The default value is the larger 
of NAXIS and the largest index of these keywords found in the 
FITS header This keyword, if present, must precede all WCS 
keywords (other than the NAXIS j). The use of this keyword 
also solves the problem posed by alternate axis descriptions 
(Sect. 2.5 ) which may have an intrinsically different coordinate 
dimensionality. In the slit example, an alternate description of 
the x,y coordinates on the detector has no use for a third axis. 
It is a good idea to provide a coordinate description, even if it 
is only a "pixel" axis, for all array axes having more than one 
pixel. 

There is debate within the communit y as to whether the 
official definition of FITS (Hanisch et al. 2001) prohibits the 
occurrence of WCS-related keywords with indices greater than 
the value of NAXIS. We make no claims one way or the other, 
but rather assert that in order to accommodate WCS spec- 
ifications whose dimensionality exceeds NAXIS without the 
use of degenerate coordinate axes, such use must be allowed. 



Consistent with Hanisch et al. (2001), however, no NAXIS 7 



keywords may exist for j > NAXIS. Thus, calculations re- 
lated to determining the total length of the data array, which 
relies upon a product of the NAXIS j values, are unaffected. 
Accordingly, all axes with axis number greater than NAXIS 
must be one pixel in length implicitly rather than explicitly. 



2.3. Keyword value units 



The original FITS paper (Wells et al. 1981) assumed that the 
units along each axis could be implied simply by the contents 
of the CTYPE / keyword. This has not turned out to be true in 
general. Therefore, we propose adding a new indexed, keyword 



CUNIT; 



(character- valued) 



with which the units of CRVAL; and CDELT; may be spec- 
ified. Restrictions on the nature and range of units, if any, 
will be determined by the agreements applying to the specific 
axes. If they are not so limited, units should conform w ith th e 
recommendations of the lAU Style Manual (McNally |l988| ). 
Particular conventions for CUNIT; values are discussed in 
Sect. Case will be significant in the values assigned to 
CUNIT; since, for example, it is necessary to represent both 
milli and Mega prefixes for units such as mJy and M Jy. The val- 
ues assigned to CUNIT; cannot exceed 68 characters, but may 
well be longer than the 8 characters which has been a traditional 
- but optional - limit for character-valued but non-mandatory 
keywords. 



WCSAXES 



(integer-valued) 



2.4. Keyword value defaults 



to specify the highest value of the index of any WCS key- 
word in the header (i.e. CRPIXy, PC;_; or CD;_;, CDELT;, 



The original FITS paper also assumed that the coordinate key- 
words, if present, would aU be present and, therefore did not 
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define defaults for the standard keywords. We therefore define 
the defauhs to be 



Table 1. Keywords with alternate axis descriptor codes. 



WCSAXES 

CRVALi 

CRPIX j 

CDELTi 

CTYPEi 

CUNIT; 

PCLj 

CD/.; 



NAXIS or largest / or j 

0.0 

0.0 

1.0 

' ' (i.e. a linear undefined axis) 
' ' (i.e. undefined) 
1.0 when / = j 
0.0 when ; j 



0.0 but see Sect. 2.1.2 



These defaults provide the minimal amount of information con- 
sistent with a real axis that is not fully described but will not 
cause zero divides. They assert that the pixel coordinate value 
changes as the pixel number changes and that, by default, co- 
ordinate values on the pixel axis depend upon that axis and 
only that axis. The reference pixel is by default just off the 
data array which satisfies the needs of some software systems 
and has the felicitous result that the coordinate value of each 
pixel is its pixel number if all of the keywords take their de- 
fault values. With these defaults, a program may fill its coor- 
dinate arrays with usable, if uninteresting, values before read- 
ing the FITS header, rather than constructing some scheme that 
changes depending on the absence of keywords in the FITS 
header Because default values were not defined from the be- 
ginning and appear to be a source of confusion, we recommend 
that FITS writers should endeavor always to write complete 
WCS specifications and never to depend upon defaults. 

2.5. Alternate axis descriptions 

In some cases, an axis of an image may be described as having 
more than one coordinate type. An example of this would be 
the frequency, velocity, and wavelength along a spectral axis 
(only one of which, of course, could be linear). One can also 
describe the position on a CCD camera chip (or photographic 
plate) in meters as well as in degrees on the sky. To allow up 
to 26 additional descriptions of each axis, we propose the ad- 
dition of the following optional, but now reserved, keywords 
defined in Table |lj where j and / are pixel and intermediate 
world coordinate axis numbers, respectively, and a is a char- 
acter A through Z specifying the coordinate version. The axis 
numbers are restricted by this convention to the range 1-99 
and the coordinate parameter m is restricted to the range 0-99, 
both with no leading zeros. Note that the primary version of 
the coordinate description is that specified with a as the blank 
character If an alternate coordinate description is specified, all 
coordinate keywords for that version must be given even if they 
do not differ from those of the primary version. Rules for the 
default values of alternate coordinate descriptions are the same 
as those for the primary description. The alternate coordinate 
descriptions are computed in the same fashion as the primary 
coordinates. The type of coordinate depends on the value of 
CTYPE ia and may be linear in one of the alternate descriptions 
and non-linear in another. 

Alternate axis descriptions are optional, but may only be 
specified if a primary axis description is specified. The alter- 



WCSAXESfl 


number of axes in WCS description 




(integer) 


CRVALk; 


coordinate value at reference point 




(real floating) 


CRPIX ja 


pixel coordinate of the reference point 




(real floating) 


PCi.ja 


linear transformation matrix 




(real floating) 


CDELTm 


coordinate increment 




(real floating) 


CD i.ja 


linear transformation matrix (with scale) 




(real floating) 


CTYPE 


axis type 




(8 characters) 


CUNITm 


units of CRVAL/a and CDELTw 




(character) 


PV Lma 


coordinate parameter in 




(real floating) 


PS Lma 


coordinate parameter m 




(character) 



nate version codes are selected by the FITS writer; there is no 
requirement that the codes be used in alphabetic sequence and 
no requirement that one coordinate version differ in its param- 
eter values from another 
An optional keyword 



WCSNAMEa 



(character- valued) 



is also defined to name, and otherwise document, the various 
versions of world coordinate descriptions. This keyword can 
be used to give the user simple names by which to request the 
various versions of the coordinates. It may also be used, for ex- 
ample, to distinguish coordinates used during data acquisition 
from those determined later by astrometrically rigorous reduc- 
tions. It might also be used to specify which are data pixels and 
which are caUbration pixels in a CCD image. 

2.6. Uncertainties in the coordinates 

The coordinates of a pixel may not always be known exactly. 
Instead, they are often subject to both random, statistical errors 
and various systematic errors. The former are not particularly 
correlated between pixels, whereas the latter may have a high 
degree of correlation across the whole data set. For example, 
single-dish radio images may be accurate on a pixel-to-pixel 
basis to a fraction of an arcsec, but have a 5-10 arcsec uncer- 
tainty in the reference point value. Two optional keywords are 
hereby reserved to specify these uncertainties in coordinates. 
They are 

CRDER/fl random error in coordinate 

(real floating) 
CSYER/fl systematic error in coordinate 

(real floating) 

where both are given in units of CUNITm and have default 
value zero. They are understood to give a representative av- 
erage value of the error over the range of the coordinate in the 
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data file. The total error in the coordinate would be given by 
summing the two errors in quadrature. 

The errors in actual coordinates may be very much more 
complex than this simple representation. In the most general 
case, one might require, at each pixel, a covariance matrix to 
describe the dependence of the uncertainty in one coordinate 
on the uncertainties in the others. Furthermore, the errors in 
one coordinate description may, or may not, be completely 
predictable from those of an alternate description. Such us- 
ages, while perhaps important under some circumstances, are 
well beyond the needs of most users and the scope of this 
manuscript. 



a variable length vector may be used to store different-sized 
images within the same column. 

Because two or more columns in a binary table can con- 
tain images, the naming convention for these coordinate sys- 
tem keywords must encode the column number containing the 
image to which the keyword applies as well as the axis num- 
ber within the image. The naming convention described here 
uses the keyword prefix to specify the axis number and the 
keyword suffix to specify the column number containing the 
image (e.g. the 2CRVL15 keyword applies to the second axis of 
the image in Col. 15 of the table). 



3. Alternate FITS image representations: pixel list 
and vector column elements^ 

In addition to the image format discussed in the previous sec- 
tions of this paper (i.e. an A^-dimensional array in a FITS pri- 
mary array or FITS IMAGE extension), there are two other 
FITS image representations that are used commonly by the as- 
tronomical community in binary tables extensions (Cotton et 



al. 1995) in the forms of: 



1 . a multi-dimensional vector in a single element of a FITS 
binary table, 

2. a tabulated list of pixel coordinates in a FITS ASCII or bi- 
nary table, and 

3. a combination of the two forms in a FITS binary table. 

The purpose of this section is to define a naming conven- 
tion for the coordinate system keywords to be used with these 
alternate image formats. Keywords specific to celestial coordi- 
nates will be treated in Paper II and an example will be given. 
Keywords specific to spectral coordinates will be treated in a 
section of Paper III. This general convention has been used for 
some time and is therefore considered part of the full world 
coordinates convention. 



The NOST (Hanisch et al. |2001[ ) standard provides that the 
interpretation of raw field values found in any column « of a 
FITS table (either ASCII or binary) may be transformed into 
true physical values by the presence of the keywords TZEROn 
and TSCAL« for that column. The tabular WCS keywords de- 
fined in this section (and in the corresponding tabular keyword 
sections of subsequent WCS papers) operate on the true phys- 
ical values, not on the raw field values. Therefore any trans- 
formation specified by TZEROn and TSCALn is to be applied 
before these tabular WCS computations. 

3.1. Multi-dimensional vector in a binary table 

A vector column in a binary table (BINTABLE) extension can 
be used to store a multi-dimensional image in each element 
(i.e. each row) of the column. In the simple case in which all 
the images have the same fixed size, the TDIMn keyword can 
be used to specify the dimensions. In the more general case. 



^ Contributed by William Pence, Arnold Rots, and Lorella Angelini 
of the NASA Goddard Space Flight Center, Greenbelt, MD 20771. 



3.2. Tabulated list of pixels 

An image may also be represented as a list of p\,p2, ■ ■ ■ pixel 
coordinates in a binary or ASCII table extension. This rep- 
resentation is frequently used in high-energy astrophysics as 
a way of recording the position and other properties of indi- 
vidually detected photons. This image format requires a mini- 
mum of n table columns which give the p\,p2, ■ ■ p,, (axes 1 
through «) pixel coordinate of the corresponding event in the 
virtual n-D image; any number of other columns may be in- 
cluded in the table to store other parameters associated with 
each event such as arrival time or photon energy. This virtual 
image may be converted into a real image by computing the n- 
dimensional histogram of the number of listed events that occur 
in each pixel of the image (i.e. the intensity value assigned to 
each pixel (pi, p2, ■ ■ ■ ,Pn) of the image is equal to the number 
of rows in the table which have axis 1 coordinate - pi, axis 2 
coordinate = p2), etc. 

A variation on this pixel list format may be used to spec- 
ify explicitly the intensity value of each image pixel. This case 
requires at least n + 1 table columns which specify the axis 1 
coordinate, the axis 2 coordinate, etc. plus the value of the pixel 
at that coordinate. In this representation each pixel coordinate 
would only be listed at most once in the table; pixels with a 
value = may be omitted entirely from the table to conserve 
space. 

Each axis of the image in this representation translates into 
a separate column of the table, so the suffix of the coordinate 
system keywords all refer to a column number rather than an 
axis number (e.g. the TCRP12 keyword applies to the coordi- 
nates listed in the 12* column of the table). This form of WCS 
keyword may only be used with columns containing scalar val- 
ues; the BINTABLE form must be used with columns containing 
more than one value per table cell. 

The presence of data from each column within a particu- 
lar row of a table implies an association of those data with 
each other However, no formal method has previously been de- 
fined for identifying and associating the columns which contain 
image pixel coordinates, although informal conventions using 
new keywords have been used. Past practice has been to use 
distinctive column names (e.g. TTYPEn keywords with values 
of 'DETX' and 'DETY', or 'X' and 'Y') which a human in- 
terpreter may use to form associations. However, this is not 
generally suitable for interpretation by software. 
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Table 2. Coordinate keywords for use in tables: the data type of the table keyword matches that of the primary array keyword. 
See Sect. 3.3 for the definitions of the italicized metasyntactic variables used below. 



Keyword 


Primary 


BINTABLE vector 


Pixel List 


Description 


Array 


primary 


alternate 


primary 


alternate 


Coordinate dimensionality 


WCS AXE Sa 




WCAX;ja 




- 


Axis Type 


CTYPE ia 


iCTYPn 


iCTYna 


TCTYPn 


TCTYnfl 


Axis Units 


omnia 


iCmin 


iCmna 


TCUNIn 


TCUNnfl 


Reference value 


CRVAL ia 


iCRVLn 


iCRVna 


TCRVL/! 


TCRVna 


Coordinate increment 


CDELTifl 


iCDLTn 


iCDEna 


TCDLTfi 


TCDEnfl 


RpTPi'pnpp nomf 

AVdCl Clll^t; IJVJilll 


CRPTX in 


jCRPXn 


jCRPna 


TCRPX;i 


TCRPna 


TraTTiformatinn mfitriY 


PCi ja 




ijPOia 




JPn.ka 


TraTTjfnrmatinn matriY 


CD/ ja 




ijCDna 




ICnJca 


f^rinrHinafp naranipfpr 


p V 7 in/1 








TYnjna 


Coordinate parameter array 






iVn^Xa 






Coordinate parameter 


PS i_ma 




iSnjna 




TSnjna 


Coordinate name 


WCSNAMEa 




WCSNna 




■mCSna 


Random error 


CRDER;a 




iCRDna 




JCRDna 


Systematic error 


CSYERm 




iCSYna 




TCSYna 


WCS cross-ref. target 






WCSTna 






WCS cross reference 






WCSXna 






t Coordinate rotation 


CROTAi 


/CROTn 




TCROT;i 





t CROTAi form is deprecated. It may be used only when PCi-j, PVijn, and PS ijn are not used and when a is blank. 



The keywords defined for pixel lists in Table g partially 
remedy this by identifying the pixel coordinate columns. For 
example, the presence of TCTYna in the header of a binary ta- 
ble identifies column n as containing a pixel coordinate rather 
than, say, a pixel value. In so doing it also identifies the binary 
table as a pixel list. Moreover, where a pixel list contains mul- 
tiple coordinate representations, the presence of a complete set 
of TPnJca keywords would also provide a method of associat- 
ing the coordinate axes of each representation. 

Thus, pending a formal solution of this problem, it is sug- 
gested that a complete set of TPnJca (or TCnJca) keywords be 
included in the pixel list header to define an association of co- 
ordinate axes. It should be noted that, while such an association 
is unordered, this is not a concern for the computation of world 
coordinates. 

3.3. Keyword naming convention 

Table ^ lists the corresponding set of coordinate system key- 
words for use with each type of FITS image representation. 
The data type of the table keyword matches that of the corre- 
sponding primary image keyword. The allowed values for these 
keywords are identical for all three types of images as defined 
in the main body of this paper The old and now deprecated key- 
word CROTAi has been used with tables and is included since 
readers will need to understand this keyword even if writers 
should no longer write it. See Paper II for a discussion of this 
point. To support current usage, the keywords are given in their 
current form to be used for the primary coordinate represen- 
tation (a is blank) and a new form to support the new capa- 
bility to specify alternate coordinates for the same axis (a is A 
through Z). For new keywords, the two forms are identical and 
are shown in a single column midway between the columns for 



old primary and new alternate WCS keywords. The following 
notes apply to the naming conventions used in Table ^ 

- The j, i prefix and suffix characters are integers referring to 
a pixel and intermediate world coordinate axis number, re- 
spectively, of the array. When used as a keyword suffix the 
image dimension may range from 1 to 99 with no leading 
0, but when used as a prefix the integer is limited to a single 
digit to conform to the 8 -character keyword name limit so 
the image may only contain up to 9 dimensions. 

- fl is a 1 -character coordinate version code and may be blank 
(primary) or any single uppercase character from A through 
Z. 

- n and k are integer table column number without any lead- 
ing zeros (1-999). 

- m is an integer between and 99 with no leading zero giv- 
ing the coordinate parameter number m cannot exceed 9 
when n exceeds 99, but see the following Section. 

- The guidelines given Sect. 2.3 must be applied to the the 
value of the CUNIT/a keyword and its derivatives. In par- 
ticular the value is restricted to ' deg ' when referring to 
celestial coordinates; see Paper II. 



3.4. Multiple images and the "Greenbank Convention" 

In the case of the binary table vector representation, all the im- 
ages contained in a given column of the table may not nec- 
essarily have the same coordinate transformation values. For 
example, the pixel location of the reference point may be dif- 
ferent for each image/row in the table, in which case a sin- 
gle ICRPn keyword in the header is not sufficient to record the 
individual value required for each image. In such cases, the 
keyword must be replaced by a column with the same name 
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(i.e. TTYPEm = ' ICRPn ' ) which can then be used to store the 
pixel location of the reference point appropriate for each row 
of the table. This convention for expanding a keyword into a 
table column (or conversely, collapsing a column of identical 
values into a single header keyword) is commonly known as 
part of the "Greenbank Convention" for FITS keywords and is 
illustrated in the example header shown in Paper II (Table 9). 

There are several restrictions which may be too limiting for 
the parameters of certain types of coordinates and, in particular, 
for the distortion parameters to be introduced in Paper IV. The 
limitation to 8 characters limits the number of columns to 999, 
the number of axes to 9, and the number of parameters to as 
few as 10 (numbered through 9, for column numbers exceed- 
ing 99). To avoid this difficulty, we introduce the concept of a 
parameter array as a single column of a table. All the param- 
eters of a coordinate are given up to the maximum dimension 
of the column (given by keyword TFORMn) with no omitted pa- 
rameters. Such parameter arrays are signaled by replacing the 
jn in the table column name with _X. 

The Greenbank and parameter-array conventions are not 
needed with pixel lists since they are used to represent a sin- 
gle image. 

3.5. Coordinate system cross-references 

While a coordinate representation may be shared amongst im- 
age arrays within the same column of a binary table, it may 
also happen that several image arrays within the same row of 
a binary table must share the same coordinate representation. 
For example, each row of a table might store a raw optical 
spectrum, the corresponding sky background spectrum, a flux- 
calibrated spectrum derived from these, and a spectrum of the 
error in each channel. It would not be appropriate to coerce 
these into a 2-dimensional data array with a heterogeneous sec- 
ond axis, and in any case this would complicate the addition 
or removal of spectra, say, as the result of data reduction. It 
also may not be satisfactory simply to repeate the coordinate 
description for each spectrum. For example, it would be prefer- 
able to apply a wavelength calibration to one shared represen- 
tation rather than several identical copies. 

This situation is handled by introducing coordinate system 
cross-references. These apply only to binary tables containing 
multiple image array columns, they are not relevant to primary 
image arrays or to pixel lists which represent only a single data 
set. 

Coordinate system cross-references allow an image array in 
one column to reference the coordinate system defined for an 
image array in another column. The cross-reference is specified 
by the keyword pair 

WCSTnfl (character-valued) 

for the referred-to (target) coordinate system, and 

WCSX«a (character-valued) 

for the referring (cross-referencing) system, and these must 
have identical, case-sensitive, keyword values. WCSXna must 
not be combined with any Table ^ coordinate keywords that 



Table 3. Characters & strings allowed to denote mathematical 
operations. 



String 


Meaning 


strl str2 


Multiplication 


strl*str2 


Multiplication 


strl . str2 


Multiplication 


strl/str2 


Division 


strl-'-expr 


Raised to the power expr 


strl'expr 


Raised to the power expr 


strlexpr 


Raised to the power expr 


log(strl) 


Common Logarithm (to base 10) 


In(strl) 


Natural Logarithm 


exp(strl) 


Exponential (e^^^^) 


sqrt(strl) 


Square root 



Table 4. Prefixes for multiples & submultiples. 



Submult 


Prefix 


Char 


Mult 


Prefix 


Char 


10-' 


deci 


d 


10 


deca 


da 


10-2 


centi 


c 


102 


hecto 


h 


10-3 


milli 


m 


10' 


kilo 


k 


io-« 


micro 


u 


10« 


mega 


M 


10-" 


nano 


n 


10" 


giga 


G 


10-'- 


pico 


P 


10'2 


tera 


T 


10-'-^ 


femto 


f 


10'"' 


peta 


P 


10-"* 


atto 


a 


10"* 


exa 


E 


10-2' 


zepto 


z 


102' 


zetta 


Z 


10-2" 


yocto 


y 


102" 


yotta 


Y 



use the same altern ate d escriptor. With regard to the Greenbank 
convention (Sect. 



3.4) 



when WCST/ifl and/or WCSXna are 
columns of the table, the scope of the keyword(s) is limited 
to one row of the table. Thus the same value of WCST na and 
WCSXna may be reused in different rows. 

On encountering WCSXna, FITS header-parsing software 
must resolve the reference by searching for WCSTna with the 
same value, extracting the column number and alternate de- 
scriptor suffix encoded in the keyword itself, and then search- 
ing for and loading the associated coordinate keywords. 

To continue the example above, suppose that Col. 12 con- 
tains a raw optical spectrum for which the coordinate system is 
fully specified, and that WCST 12B has been set to 'XREFl'. Then 
a sky background spectrum in Col. 13 might reference this co- 
ordinate system by setting WCSX13A = ' XREFl ' . In this case. 
Col. 13 must not contain any of the Table ^ key words for alter- 
nate descriptor a = A, although it might contain keywords for 
some other value of a. The example illustrates that the alternate 
descriptor suffixes for WCST na and WCSXna need not match; the 
association is via the keyword value alone. 
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Table 6. Additional allowed units. 



Quantity 




Unit 
String 


Meaning 


Notes 


plane angle 




deg 


degree of arc 


tt/ 180 rad 






arcmin 


minute of arc 


1/60 deg 






arcsec 


second of arc 


1/3600 deg 






mas 


milli-second of arc 


1/3600000 deg 


time 




min 
h 


minute 
hour 








d 


day 


86400 s 




t 


a 


year (Julian) 


31557600 s (365.25 d), peta a (Pa) forbidden 




t 


yr 


year (Julian) 


a is lAU-style 


energy* 


T 


eV 


electron volt 


t.oUzt /uj X lU J 




-I- 


erg 


erg 


iU J 

ki^") m,c- = 13.605692 eV 






Ry 


rydberg 


mass* 




solMass 


solar mass 


1.9891 X 10^" kg 






u 


unified atomic mass unit 


1.6605387 X lO^^' kg 


luminosity 




SOlLlM 


Solar luminosity 


3.8268 X 10^6 W 


length 


i 


Angstrom 


angstrom 


10-'° m 






solRad 


Solar radius 


6.9599 X lO** m 






AU 


astronomical unit 


1.49598 X 10" m 






lyr 


light year 


9.460730 X 10'' m 




t 


pc 


parsec 


3.0857 X 10'^ m 


events 




count 
ct 

photon 
ph 


count 
count 
photon 
photon 




flux density 


t 


Jy 


jansky 


10-26 W m-2 Hz-i 




t 


mag 


(stellar) magnitude 






T 


K 


rayleigh 


10'°/(4;r) photons m-^ s-' sr-' 


magnetic field 


it 


G 


gauss 


lO-"* T 


area 




pix 


(image/detector) pixel 
(image/detector) pixel 








bcirn 


bam 


10-28 ^2 








Miscellaneous "units" 






D 


debye 


i X 10-2' Cm 






Sun 


relative to Sun 


e.g. abundances 






chan 


(detector) channel 








bin 


numerous applications 


(including the 1-d analogue of pixel) 






voxel 


3-d analogue of pixel 






t 


bit 


binary information unit 






t 


byte 
adu 


(computer) byte 
Analog-to-digital converter 


8 bit 






beam 


beam area of observation 


as in Jy/beam 



t - addition of prefixes for decimal multiples and sti bmultiples are allowed. 
$ - deprecated in lAU Style Manual (McNally 1988 ) but still in use. 

* - conversion factors from CODAIAInternationall^recOT : / /physics . 

nist.gov/cuu/Constants/) 



4. Specification of units 



Unless agreed otherwise, units should conform with the rec- 



ommendations of the lAU Style Manual (McNally 1988) 



Unfortunately, this manual defines units as they would ap- 
pear in a published document rather than as they must ap- 



pear in plain character form. George & Angelini (1995) and 



Ochsenbein et al. (1996) have prepared detailed documents 



on this subject upon which the following remarks are based. 
In particular, the following tables are taken from George & 
Angelini's manuscript (with some changes and additions). 
Readers should consult these references for examples and ex- 
panded discussion. We allow the possibility that the interpreta- 
tion of CUNIT/fl may depend on conventions established for the 
CTYPE ia associated with them. For example, units specified by 
"s" might mean SI seconds or seconds of sidereal time. 



12 



E. W. Greisen and M. R. Calabretta: Representations of world coordinates in FITS 



Table 5. lAU-recommended basic units. 



Quantity 


Unit 
String 


Meaning 


Notes 


5/ base Cr supplementary units 






length 


m 


meter 




mass 


kg 


kilogram 


g gram okay 


time 


s 


second 




plane angle 


rad 


radian 




solid angle 


sr 


steradian 




temperature 


K 


kelvin 




electric current 


A 


ampere 




amount of substance 


mol 


mole 




luminous intensity 


cd 


candela 




lAU-recognized derived units 






frequency 


Hz 


hertz 


S-' 


energy 


J 


joule 


Nm 


power 


W 


watt 


Js-i 


electric potential 


V 


volt 


JC' 


force 


N 


newton 


kg m s"' 


pressure, stress 


Pa 


pascal 


N m"2 


electric charge 


C 


coulomb 


As 


electric resistance 


Ohm 


ohm 


V A"' 


electric conductance 


S 


Siemens 


A 


electric capacitance 


F 


farad 


c 


magnetic flux 


Wb 


weber 


V s 


magnetic flux density 


T 


tesla 


Wbm-2 


inductance 


H 


henry 


Wb A^' 


luminous flux 


Im 


lumen 


cd sr 


illuminance 


Ix 


lux 


Im m"- 



The basic units string, called strl and str2 in Table ||, 
is composed of a unit string taken from Col. 2 of the lAU- 
recognized units in Table || or the extended astronomical units 
in Table |[ All units from the former and selected units from the 
latter may be preceded, with no intervening blanks by a single 
character (two for deca) taken from Table ^ and representing 
scale factors mostly in steps of 10^. Compound prefixes (e.g., 
ZYeV for 10"*^ eV) are prohibited. A compound string may then 
be created from these simple strings by one of the notations 
in Table |^. A unit raised to a power is indicated by the unit 
string followed, with no intervening blanks, by the optional 
symbols or " followed by the power given as a numeric 
expression, called expr in Table ^ The power may be a simple 
integer, with or without sign, optionally surrounded by paren- 
theses. It may also be a decimal number (e.g., 1.5, .5) or a ra- 
tio of two integers (e.g. 7/9), with or without sign, which are 
always surrounded by parentheses. Thus meters squared is in- 
dicated by m-"' (2), m""""+2, m-i-2, m2, m"2, m" C-i-2), etc. and per 



meter cubed is indicated by m'"''-3, m-3, m" (-3), /ra3, and so 
forth. Meters to the three halves may be indicated by m(l . 5), 
m"(1.5), in**(1.5), m(3/2), m**(3/2), and m"C3/2), but 
nof by m"3/2 or ml . 5. 

Note that functions such as log actually require dimen- 
sionless arguments, so, by log (Hz), for example, we actually 
mean log(jc/lHz). The final string to be given as the value 
of CUNIT/a is the compound string, or a compound of com- 
pounds, preceded by an optional numeric multiplier of the form 
10" "A:, W~k, or 10±A: where k is an integer, optionally sur- 
rounded by parentheses with the sign character required in the 
third form in the absence of parentheses. FITS writers are en- 
couraged to use the numeric multiplier only when the available 
standard scale factors of Table Q will not suffice. Parentheses 
are used for symbol grouping and are strongly recommended 
whenever the order of operations might be subject to misin- 
terpretation. A blank character implies multiplication which 
can also be conveyed explicitly with an asterisk or a period. 
Therefore, although blanks are allowed as symbol separators, 
their use is discouraged. Two examples are ' 10"- (46) erg/ s ' 
and ' sqrt(erg/pixel/s/GHz) ' . Note that case is signif- 
icant throughout. The lAU style manual forbids the use of 
more than one solidus (/) character in a units string. In the 
present conventions, normal mathematical precedence rules are 
assumed to apply, and we, therefore, allow more than one 
solidus. However, authors might wish to consider, for exam- 
ple, ' sqrt (erg/ (pixel . s .GHz)) ' instead of the form given 
previously. 

5. Additional matters 

5.1. Image display conventions 

It is very helpful to adopt a convention for the display of images 
transferred via the FITS format. Many of the current image 
processing systems have converged upon such a convention. 
Therefore, we recommend that FITS writers order the pixels so 
that the first pixel in the FITS file (for each image plane) be the 
one that would be displayed in the lower-left corner (with the 
first axis increasing to the right and the second axis increasing 
upwards) by the imaging system of the FITS writer. This con- 
vention is clearly helpful in the absence of a description of the 
world coordinates. It does not preclude a program from looking 
at the axis descriptions and overriding this convention, or pre- 
clude the user from requesting a different display. This conven- 
tion also does not excuse FITS writers from providing complete 
and correct descriptions of the image coordinates, allowing the 
user to determine the meaning of the image. The ordering of 
the image for display is simply a convention of convenience, 
whereas the coordinates of the pixels are part of the physics of 
the observation. 

5.2. Units in comment fields 

If the units of the keyword value are specified in the comment 
of the header keyword, it is recommended that the units string 
be enclosed in square brackets at the beginning of the comment 
field, separated from the slash ("/") comment field delimiter by 
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Table 7. Conventional Stokes values. 



Value 


Symbol 


Polarization 


1 


1 


Standard Stokes unpolarized 


2 


Q 


Standard Stokes linear 


3 


u 


Standard Stokes linear 


4 


V 


Standard Stokes circular 


-1 


RR 


Right-right circular 


-2 


LL 


Left-left circular 


-3 


RL 


Right-left cross-circular 


-4 


LR 


Left-right cross-circular 


-5 


XX 


X parallel linear 


-6 


YY 


Y parallel linear 


-7 


XY 


XY cross linear 


-8 


YX 


YX cross linear 



a single space character. This widespread, but optional, conven- 
tion suggests that square brackets should be used in comment 
fields only for this purpose. Nonetheless, no software should 
depend on there being units expressed in this fashion within 
a keyword comment, nor should any software depend on any 
string within square brackets in a comment field containing a 
proper units string. This convention is purely for the human 
reader, although software could be written which would inter- 
pret the string only if present and of proper content. If there is 
an established convention for the units of a keyword, then only 
those units may be used. An example, using a non-standard 
keyword, is 

EXPTIME = 1200. / [s] exposure time in seconds 



5.3. Tables 



Binary extension tables (Cotton et al. 1995 ) use the NAXIS2 
keyword, invented for simple images, to specify the number of 
rows in a table. It has been suggested that, if the rows of the 
table are regularly spaced in some world coordinate, that world 
coordinate could be described with the other axis-2 keywords 
such as CTYPE2fl, CRVAL2fl, CDELT2fl, and PC2_2fl. Since we 
know of no software system using this convention with these 
general keywords, we deprecate the suggestion. There are very 
powerful and useful general operators such as sorting, editing, 
and concatenation which alter the value of the row number and 
therefore corrupt the value of the implied coordinate. If FITS 
were solely used as an interchange mechanism, these operators 
would not be relevant. But FITS is now used as the internal 
format of several software systems for which the general op- 
erators are important. Initial row number can be recorded as a 
column in tables and associated with a physical coordinate via 
keywords described in Sect. ||. 

5.4. Conventional coordinate types 



that they can assume only integer coordinate values and that 
the meaning of these integers is only by convention. These two 
axis types are in wide-spread use and we wish to repeat their 
definition here to extend their definitions and to reserve their 
names and meanings. 

The first conventional coordinate is CTYPE ia = ' COMPLEX ' 
to specify complex valued data. FITS data are limited to a sin- 
gle real number value at each pixel making this axis neces- 
sary to represent data which are weighted complex numbers. 
Conventional values of 1 for the real part, 2 for the imaginary 
part, and 3 for a weight (if any) have been widely used. 

The second conventional coordinate is CTYPE /a = 
' STOKES ' to specify the polarization of the data. Conventional 
values, their symbols, and polarizations are given in Table 0. 

6. Header construction example 

A simple header construction example based on Einstein's 
Special Theory of Relativity (1905) will serve to illustrate the 
formalism introduced in this paper. We will construct dual co- 
ordinate representations, the first for the rest frame and the sec- 
ond for an observer in uniform motion. 

Suppose we have a data cube that, in the rest frame, has the 
following simple header containing two spatial axes and one 
temporal axis; 



NAXIS 




3, 




CTYPE 1 




'X' , 


NAXISl 




2048, 




CTYPE2 




'Y' , 


NAXIS 2 




2048, 




CTYPE 3 




'TIME' , 


NAXIS 3 




128, 




CRVALl 




0.0, 


CRPIXl 




1024. 


5, 


CRVAL2 




0.0, 


CRPIX2 




1024. 


5, 


CRVAL3 




0.0, 


CRPIX3 




64.5, 




CUNITl 




'km' , 


CDELTl 




3.0, 




CUNIT2 




'km' , 


CDELT2 




3.0, 




CUNIT3 




'us' , 


CDELT3 




10.0, 




WCSNAME 




'Rest frame' 



This describes three linear coordinate axes with the reference 
point in the middle of the data cube. 

The spatial and temporal coordinates measured by an ob- 
server moving with uniform velocity v in the +x direction are 
related to the rest coordinates by the Lorentz transformation: 

x' — yix — vt) , 

y' - y, 

t' = y(f - vx/c^) , 
where 



In the first FITS paper. Wells et al. (1981) listed a number of 



y = 1/ Vl - v2/c2, 

and c is the velocity of light. Time in each system is measured 
from the instant when the origins coincide. From the above 
header we have 

X = siipi -n), 
y = S2(p2 - n) , 

t = i3(/73 - rs) , 



■'suggested values" for CTYPE/. Two of these have the attribute where, Vj and si are given by CRPIX j and CDELT;. Thus 
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Table 8. Coordinate keywords: see also Table ^for alternate types used in binary tables. 



Keyword Type 



Sect. Use 



Status 



Comments 



CRVAL;a 
CRPIX ja 
CDELTm 
CROTAi 
CTYPEm 



CUNITm 

PCLya 

CDiJa 



WCSNAMEfl 
CRDERm 



WCSAXESfl integer 2.2 WCS dimensionality 



floating [2.1. l| value at reference point 

floating [2.1. l| pixel of reference point 

floating [2.1. l| increment at ref. point 

floating III rotation at ref. point 

character [2.1. l| coord./algorithm type 



character 2.3 units of coord, values 



floating 2.1.2 transformation matrix new 



floating 2.1.2 transformation matrix new 



PV ijna floating [2.1.4] parameter j 



PS ijna character [2.1.4] parameter m 



character 2.5 coord, version name 



floating l.t random error 



CSYERia floating l.t systematic error 



new allows WCS specification for degenerate axes, 

to be explicit rather than implicit. 

extended meaning of reference point forced by coord, type. 

extended meaning of reference point forced by coord, type. 

retained meaning of increment clarified. 

deprecated replaced by PC i.j and CD i.j. 

extended Non-linear types have "4-3" form: characters 1-4 
specify the coordinate type, character 5 is 
and characters 6-8 specify an algorithm code 
for computing the world coordinate value; 
case dependent. 

new case dependent, allowed values and combinations 

are described in Sect. ^ 

linear conversion of pixel number to pixels along 
coordinate axes; default = (it j), =1 (; = j). 
linear conversion of pixel number to relative 
coordinates; default all if any given, 
else PC z_j applies, 
new parameters required in some coordinate types; 

defaults are algorithm-specific; see Papers 11 and 
111 for usage examples and default conventions 
new parameters required in some coordinate types; 

defaults are algorithm-specific; see Paper 111 
for usage example and default conventions 
new optional documentation 

new uncertainty in coordinate due to random errors; 

default = 

new uncertainty in coordinate due to systematic 

errors; default = 



where j is a pixel axis number 1 through 99, i is an intermediate world coordinate axis number 1 through 99, m is a parameter number 
2 through 99, and a is a coordinate description version character blank and A through Z. PCi_ja and CD ;_ja may not occur in the same header 
data unit. 



y' = S2(p2 - ri) , 

t' = ys^ip^ - r^) -yv/c^si(pi - ri) . 

This set of equations may be rewritten to make the scales, 
CDELTi, the same as the rest frame header: 

x' = si[y{pi-ri)-yvsi/si(pi-r3)], 
y' = S2[ip2 - r2)] , 

t' = S3[y(pi - r3) -yv/c^si/s2(pi - ri)] . 

Using character "V" as the alternate representation descriptor, 
a, for the relatively moving frame, we have 



CRPIX IV = 


1(524. 5, 


CTYPEIV = 


'X' , 


CRPIX2V = 


1(824.5, 


CTYPE2V = 


'Y' , 


CRPIX3V = 


64.5, 


CTYPE3V = 


'TIME' , 


PCl.lV = 




CRVALIV = 


0.0, 


PC1_3V = 


-yv/ cr , 


CRVAL2V = 


0.0, 


PC3.1V = 


—ycrv/c- , 


CRVAL3V = 


0.0, 


PC3.3V = 




CUNITIV = 


'km' , 


CDELTIV = 


3.0, 


CUNIT2V = 


'km' , 


CDELT2V = 


3.0, 


CUNIT3V = 


'us' , 


CDELT3V = 


10.0, 


WCSNAMEV = 


'Moving frame' 



Note that the elements of the PC/Lj matrix are all dimension- 
less, o" = Si/s3 - 3 X lO'^ms"' having the dimensions of a 
velocity. However, in this instance we have seen fit not to ap- 
ply the strictures of Eq. in normalizing the matrix. In fact, 
in Minkowski space-time the concept of "distance", on which 
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Eq. (Q) relies, differs from the Euclidean norm, the invariant 
being 

d - ^x- +y- + - c^fi , 

so one may query the fundamental validity of Eq. (Q) in this 
case. However, the intent of that equation is well served since 
PC ij and CDELT ; are divided in a physically meaningful way, 
especially considering that y is often close to unity so that PC i_j 
is approximately the unit matrix. Nevertheless, the appearance 
of the factor y in each of the elements of PC;_j suggests the 
factorization 

PCl.lV = 1, CDELTIV = 3.0y, 

PC1.3V = -v/o-, CDELT2V =3.0, 
PC3_1V = -v/c-cr, CDELT3V = lO.Oy, 
PC3_3V = 1, 

and indeed this does also have a physically meaningful inter- 
pretation in that the scales are dilated by the Lorentz-Fitzgerald 
contraction factor, y. 
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7. Summary 

The changes to FITS -header keywords are summarized in 
Table ^. As described in Paper 11, for one purpose, CROTA; may 
in some cases be used instead of the new keywords so that the 
coordinate information may be understood by software systems 
which have yet to be converted to these new conventions. 
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